Computer systems are commonly employed for displaying graphical objects on a display screen. One purpose of three dimensional (3-D) computer graphics is to create a two-dimensional (2-D) image on a computer screen, and realistically represent an object or objects in three dimensions. Such images created with 3-D computer graphics are used in a wide range of applications
For example, different video games and television events or programs employ theses images, and are specifically marketed to specific life styles, target age groups, and the like. Similarly, head mounted computer displays enable users to experience a graphical environment, wherein a user can enjoy an illusion of presence in the displayed environment. In general, such software for generating virtual reality environments have typically been employed for training and entertaining of personnel, wherein relatively inexpensive computing devices enable 3D virtual reality user interfaces. These 3D virtual reality worlds allow a user to explore a simulated environment. Such environments can further include views from an ordinary street scene with walkways, roads, and buildings to a completely fictitious landscape of an outer space planet. In general, the end goal with virtual reality interfaces still remains to provide the user the most realistic experience possible.
Rendering and displaying 3-D graphics typically involves a plurality of calculations and computations. For example, to render a 3-D object, a set of coordinate points or vertices that define an object to be rendered is initially formed, wherein vertices are subsequently joined to form polygons and define surfaces. Once such defining vertices are formed, a transformation from an object or model frame of reference to a world frame of reference and subsequently to 2-D coordinate is completed. Throughout such procedure, vertices can be rotated, scaled, eliminated or clipped (if they fall outside of a viewable area) lit by various lighting schemes and sources, colorized, and the like. Such processes for rendering and displaying a 3-D object can be computationally intensive and can involve a large number of operations for each vertex.
For example, complexities can arise within the shading process that describes appearance of a material at any point of a 1-D, 2-D or 3-D space, via a function (e.g., procedural shader) in a shading parameter space. In general, the object is “immersed” in the original 1-D, 2-D or 3-D space and the values of shading parameters at a given point of surface are defined as a result of procedural shading function at such point. For instance, procedural shaders that approximate appearance of wood, marble or other natural materials have been developed. Moreover, by passing source code designed to work with a shader into an application, a shader becomes an object that the application can create/utilize in order to facilitate the efficient drawing of complex video graphics.
Moreover, often video cards have integrated video capture functionality, wherein captured video frames are placed in video memory (VRAM). In such units, standard mechanism for processing the frames while remaining in VRAM can become challenging—e.g., complexities associated with: copying data into system memory, processing thereof, and subsequently copying back to VRAM for display. Also requirements such as: increased stability when splitting drivers, virtualized memory allocation, security and the ability to multitask with the graphics processor (GPU), can further increase the challenges involved. For example, game users can experience situations where alt tabbing out of a game can force a lost device state in the application. When focus returns to the game, it may become necessary to re-create all resources and reset the device which in the best case took time and in the worst case caused crashing bugs. Users now desire switching focus between application with little penalty, during driver upgrades, physical removal of the device, GPU reset and unexpected errors, for example.
Furthermore, in Windows XP, display drivers, which are large and complex, can be a major source of system instability. Such drivers typically execute entirely in kernel mode (e.g., deep in the system code) and hence a single problem in the driver will often force the entire system to reboot. Additionally, a typical requirement to include code for the support of various device driver interfaces—introduced over many years—can further complicate optimal functionality.